The Internet has proven to be a popular and effective method of distributing content. For example, many people access one or more Web sites on the World Wide Web (WWW) each day. Numerous types of content may be accessed using the Internet, such as a Web page, an image file, and streaming video, to name a few examples.
A Content Delivery Network (CDN) is a network infrastructure that deploys many cache servers worldwide to provide content caching for CDN customer Websites. CDN enables the scalability and high availability for content providers without requiring them to invest in expensive Internet infrastructure. CDN global traffic management (GTM) directs Internet requests from end user clients for CDN customer Websites to those cache servers according to load-balancing parameters such as the service availability, network proximity, and system load. The cache server selection is performed by a server load balancer (SLB). Whenever there is a cache miss or client requests are for contents that are dynamic, the cache servers forward the requests to customer origin Web servers, get responses from the customer origin Web servers, and send the responses to the requesting clients.
The SLB spreads the load generated by multiple clients and the risk of failure across multiple servers; each flow from a client is processed by the SLB and assigned accordingly. One issue that arises with this mechanism is so-called session persistence. For example, downloading a Web page, entering information, loading a shopping cart, and purchasing items are all considered to be part of one session for a client. But for an SLB, these are considered to be tens or hundreds of individual sessions or flows.
A Web page consists of many elements or objects, each of which is requested separately. Filling a shopping cart is done by viewing a user multiple Web pages and entering data where desired. When a purchase is performed, the transaction entails moving from HTTP to a secure SSL mode then back again. The shopping cart information is usually stored on the same server as the SSL session. Without session persistence, the SLB would see all these flows as distinct events to be load balanced and the shopping cart information would be scattered over the pool of servers.
One solution is to send the client's requests to the same server each time. Ideally, this would be accomplished by looking at the client's IP address, matching it to previously assigned flows and sending the client to the same server. For a new request, the load-balancing algorithm of choice is used to assign the client to a server. Client-to-server bindings should have a timeout feature that enables a client to visit other sites and still return and connect to the same server, without being assigned to an entirely new server and losing previously entered data.
Most sites mix applications, using HTTP for Web pages, SSL for secure transactions, and an audio or video engine for media streaming. Because each of these sessions uses different port numbers, each is considered by an SLB to be a distinct session. With Sticky Ports, however, the SSL session will be assigned to the same server as the HTTP session. Assigning it to the same server is accomplished by enabling the option during installation of a virtual server. The software allows the administrator to select a configuration that associates multiple application port numbers together.
When a new session arrives at the SLB, the SLB looks to see if a session binding to a server exists between the client IP address and the virtual server IP address and port number combination, or any of the other virtual server port numbers in the sticky port grouping. If a binding already exists between the client and a server, then the new session is sent to the same server. If there is no current binding, then the load balancing algorithm selects the server to which the client session should be sent.
Another issue that must be addressed is when a client goes through a proxy server. Whether as a security precaution or as a way to save public IP address numbers, some proxy servers make all traffic coming from the network they are serving appear to be originating from the same IP address. This is done using a technique known as Network Address Translation (NAT). It is possible that a client may use one IP address for HTTP traffic and another for the SSL (or other port) traffic. The SLB would see this as traffic coming from two different clients and potentially assign the supposed clients to different servers, causing shopping cart data to be unavailable for the checkout application. This problem is solved using one of two techniques: delayed binding or Intrinsic Persistence Checking.
In a delayed binding mode, the SLB initiates a TCP session with each new flow request. To the client it appears that it is talking to the end server and starts to send data to the SLB, which reads the first packet of information and looks for client-specific information. In an HTTP mode, the SLB looks for “cookies” that it or one of the servers has inserted. In an SSL mode, by comparison, the SLB looks at the SSL session ID. In either case, the SLB compares this information with its stored table of server bindings and picks the real server to which the client should go. The SLB then initiates a session with the server, looking like the client, and connects the two together. This is an extremely software-intensive process that puts a limit on the throughput of the SLB and currently works only with SSL or HTTP sessions. In addition, the Sticky Port feature must be running to ensure that the SSL and HTTP traffic goes to the same server.
Another mechanism, called Intrinsic Persistence Checking, manages persistence based on an IP address range instead of source IP address only. The load-balancer accomplishes persistence by applying a “netmask” to the client IP address and comparing the result to existing client/server bindings. If one exists already, then the client is sent to the same server; otherwise, the selected SLB algorithm will choose the server.
Typically the origin server in a CDN is responsible for managing persistence. When the origin server faces heavy traffic, the burden of managing persistence can adversely affect its ability to respond to client requests.